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1.  INTRODUCTION 


This  final  technical  report  summarizes  the  accomplishments  and  lessons  learned  under  the  Joint 
Synthetic  Battlespace  for  Research  and  Development  (JSB-RD)  contract.  JSB-RD  is  a 
distributed  simulation  environment  that  is  intended  to  support  advanced  research  and 
development  of  Air  Force  C4ISR  systems  at  the  Air  Force  Research  Laboratory  (AFRL),  Rome 
Research  Site  (RRS).  This  work  was  performed  by  Northrop  Grumman  Mission  Systems 
(NGMS)  for  the  AFRL,  C4ISR  Modeling  and  Simulation  Branch  (IFSB),  under  Contract 
F30602-98-D-03 18/0045.  This  report  addresses  CLIN  0002,  CDRL  A002  of  that  contract. 

The  overall  goal  of  this  effort  was  to  develop  a  flexible  Command,  Control,  Communications, 
Computers,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR)  distributed  modeling  and 
simulation  environment  at  the  AFRL  Rome  Research  Site.  The  JSB-RD  synthetic  battlespace 
addresses  three  objectives: 

1.  To  provide  a  testbed  for  C4ISR  research,  experimentation,  and  evaluation,  supporting 
AFRL  C4ISR  concepts  and  programs  such  as  Predictive  Battlespace  Awareness  (PBA), 
the  Commander’s  Predictive  Environment  (CPE),  Effects  Based  Operations  (EBO),  and 
the  Advanced  Technology  Air  Operations  Center  (ATAOC),  and  using  communications 
infrastructures  being  developed  by  AFRL,  such  as  the  Joint  Battlespace  Infosphere  (JBI). 

2.  To  explore  the  synchronization  of  simulations  to  real-world  situation  data  in  order  to 
predict  future  events,  supporting  concepts  such  as  Dynamic  Situation  Awareness  and 
Prediction  (DSAP)  and  Course  of  Action  (COA)  Analysis. 

3.  To  support  research  into  simulation  science,  particularly  in  the  areas  of  adversarial 
modeling,  information  management,  and  visualization. 

The  JSB-RD  distributed  simulation  environment  was  constructed  primarily  by  integrating 
existing  simulations  and  tools.  The  JSB-RD  environment  is  centered  around  the  Joint  Semi- 
Automated  Forces  (JSAF)  simulation  software.  JSAF  is  a  computer  generated  forces  (CGF) 
system  that  is  used  by  the  U.S.  Joint  Forces  Command  for  joint  experimentation.  The  JSB-RD 
environment  also  includes  the  Ocean,  Atmosphere,  and  Space  Environmental  Services  (OASES) 
system,  which  models  weather,  and  the  Dynamic  Terrain  Simulation  (DT-SIM),  which  models 
changes  to  the  environment  such  as  bomb  craters,  damage  to  buildings,  and  the  creation  and 
destruction  of  obstacles,  as  well  as  a  clutter  simulation,  which  models  civilian  traffic.  The 
environment  also  includes  tools  for  creating  scenarios  from  existing  Air  Battle  Plans,  extracted 
from  the  Air  Operations  Data  Base  (AODB)  with  the  Theater  Battle  Management  Core  System 
(TBMCS),  as  well  as  gateways  for  connecting  simulations  communicating  using  DMSO’s  High 
Level  Architecture  (HLA)  and/or  the  earlier  Distributed  Interactive  Simulation  (DIS)  protocol, 
with  C4ISR  systems,  using  AFRL’s  JBI. 

Section  2  describes  the  JSB-RD  environment  in  more  detail.  Section  3  summarizes  the  lessons 
learned  in  the  course  of  performing  this  effort,  including  recommendations  for  subsequent 
related  work.  Section  4  contains  a  list  of  acronyms. 
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2.  JSB-RD  DISTRIBUTED  SIMULATION  ENVIRONMENT 


As  noted  above,  the  JSB-RD  distributed  simulation  environment  consists  of  a  number  of 
components,  which  are  connected  together  using  several  different  mechanisms.  Fundamentally, 
the  environment  is  an  HLA  federation  made  up  of  simulations  that  communicate  using  a 
variation  of  the  Millenium  Challenge  2002  (MC02)  Federation  Object  Model  (FOM). 
Simulations  that  still  use  the  DIS  protocol  can  be  connected  through  a  DIS-HLA  gateway 
federate.  Similarly,  an  HLA-JBI  gateway  allows  the  federation  to  communicate  with  C4ISR 
system  component  prototypes  being  developed  at  AFRL. 

2.1  Overall  Architecture 

The  overall  architecture  of  the  JSB-RD  distributed  simulation  environment  is  shown  in  Figure 
2.1.  It  consists  of  three  primary  components,  addressing  each  of  the  three  primary  aspects  of  any 
simulation  environment.  At  the  bottom,  the  Preparation  component  addresses  experiment 
planning,  scenario  preparation,  and  all  other  aspects  of  preparing  a  simulation  experiment.  This 
includes  accessing,  extracting,  and  manipulating  various  kinds  of  source  data,  including  Air 
Battle  Plan  (ABP)  and  Friendly  Air  Order  of  Battle  information  contained  in  the  AODB,  and 
Enemy  Order  of  Battle  (EOB)  information  contained  in  the  MIDB,  as  well  as  geospatial  data. 
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JSB-RD 

External 

Simulation(s) 


n 

C4ISR 

Integrated  |  Embedded 

Situation  Viewer  Simulation(s) 

D 

Preparation 


Figure  2.1.  JSB-RD  Overall  Architecture 


In  the  middle  are  the  components  that  address  the  execution  phase  of  a  simulation  experiment. 
These  consist  of  the  various  simulations  that  make  up  the  JSB-RD  environment,  as  well  as  real 
C4ISR  systems,  system  components,  or  prototypes.  Note  that  the  C4ISR  component  can  also 
include  an  embedded  simulation  within  it,  used  for  COA  analysis  or  other  forms  of  prediction. 
The  simulation  and  C4ISR  components  communicate  with  one  another  in  both  directions.  The 
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status  of  friendly  entities,  and  of  visible  opposing  entities,  and  the  effects  of  any  relevant 
scenario  events,  are  reported  by  the  simulation  to  the  C4ISR  system,  via  various  modeled  sensor 
and  communication  systems.  As  the  C4ISR  system  issues  commands,  they  are  passed  back  to 
the  simulated  entities  that  are  to  carry  them  out.  In  the  center,  visualizing  both  the  simulation 
and  C4ISR  information,  either  separately  or  together,  is  the  Integrated  Situation  Viewer 
application. 

At  the  top,  the  Evaluation  component  provides  a  collection  of  tools  for  analyzing  data  produced 
by  both  the  simulation  and  C4ISR  systems.  This  component  addresses  the  post-execution 
aspects  of  a  simulation  experiment.  It  is  currently  the  least  developed  part  of  the  JSB-RD 
environment. 

2.2  JSB-RD  Components 

The  components  of  the  JSB-RD  distributed  simulation  environment  are  shown  in  Figure  2.2. 
JSAF,  OASES,  and  several  supporting  simulations  make  up  an  HFA  federation.  The  HFA/XME 
Gateway  translates  the  federation  message  traffic  into  an  XME  stream  that  can  be  easily  read  by 
a  variety  of  applications.  One  such  application  is  the  Integrated  Situation  Viewer,  which 
receives  and  displays  entity  state  and  interaction  infonnation.  The  Simulation  Preparation  tool 
extracts  Air  Battle  Plan  and  Friendly  Order  of  Battle  information  from  the  AODB,  and  Enemy 
Order  of  Battle  infonnation  from  the  MIDB,  which  it  then  uses  to  generate  a  scenario  input 
spreadsheet  that  can  be  read  by  JSAF  to  create  and  task  the  necessary  simulation  entities.  The 
Simulation  Preparation  tool  also  interfaces  with  an  aircraft  route-planning  tool  created  at  AFRF 
to  generate  more  realistic  air  mission  flight  paths  that  avoid  known  threats. 

2.2.1  JSAF 

JSAF  is  currently  the  primary  simulation  used  within  the  JSB-RD  environment.  As  noted  above, 
JSAF  is  an  entity-level,  computer  generated  forces  (CGF)  simulation  system  that  is  used  by  the 
U.S.  Joint  Forces  Command  for  joint  experimentation,  by  the  U.S.  Navy  for  Fleet  Battle 
Experiments,  and  by  the  AFRF  Human  Effectiveness  Directorate  (AFRF/HE)  in  support  of  the 
Distributed  Mission  Training  (DMT)  program.  JSAF  provides  entity-level  simulation  of  ground, 
air,  and  naval  forces.  In  support  of  the  joint  experiment  Urban  Resolve,  it  has  been  used  by 
JFCOM  to  simulate  more  than  100,000  entities  within  a  single  distributed  simulation.  It  has  also 
been  used  to  support  a  variety  of  experiments  with  environment  simulation,  including  dynamic 
terrain  (i.e.,  craters,  trenches,  etc.),  weather,  and  chemical/biological  warfare  defense,  as  part  of 
DMSO’s  EnviroFed  program.  JSAF  was  originally  developed  by  DARPA  as  part  of  its  Synthetic 
Theater  of  War  (STOW)  program,  and  is  descended  from  ModSAF.  It  is  currently  maintained  by 
the  Joint  Forces  Command  (JFCOM).  It  incorporates  intelligent  agents,  due  to  the  Soar 
program,  that  autonomously  control  simulated  fixed  wing  aircraft. 
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Figure  2.2.  JSB-RD  Components 


JSAF  is  an  extremely  large  software  application.  It  was  originally  developed  more  than  15  years 
ago,  in  C,  and  has  been  extensively  modified  and  extended.  As  a  result,  its  original  architecture 
has  been  almost  completely  obscured.  It  now  consists  of  more  than  1000  object  libraries  that 
model  different  types  of  platforms,  weapons,  sensors,  etc.  While  it  contains  a  great  deal  of 
powerful  simulation  functionality,  it  is  difficult  to  use,  and  even  more  difficult  to  modify. 
Documentation  and  support  are  both  extremely  limited. 

JSAF  runs  under  the  Linux  operating  system.  In  the  JSB-RD  environment,  JSAF  can  be  run  on 
multiple  (currently  up  to  nine)  Linux  systems  simultaneously.  The  individual  copies  function 
together  as  a  single  HLA  federate,  keeping  their  separate  internal  database  copies  in 
synchronization,  and  sharing  the  computational  load. 

The  primary  input  to  JSAF  is  a  spreadsheet  file  that  defines  a  collection  of  entities,  both  friendly 
and  enemy,  to  be  created,  and  specifies  how  each  entity  is  to  be  tasked.  Entity  types,  initial 
locations,  call  signs,  and  assigned  tasks  are  identified.  Such  spreadsheets  can  be  prepared  by 
hand.  However,  they  can  also  be  automatically  generated  from  Air  Battle  Plan  information, 
supported  by  Friendly  and  Enemy  Order  of  Battle  information,  extracted  from  the  AODB  and 
MIDB  within  TBMCS. 
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JSAF  scenarios  can  also  be  created  interactively,  using  its  integral  Unit  Editor.  Individual 
entities  and  small  units  can  be  created,  placed  on  the  Plan  View  Display,  and  assigned  tasks  to 
perform.  Interactively  created  scenarios  can  be  saved  and  (re)loaded.  However,  such  scenarios 
and  the  scenario  spreadsheets  are  two  separate  mechanisms,  and  cannot  be  readily  combined. 
There  is  currently  no  mechanism  that  allows  JSAF  entities  to  be  tasked  by  other  federates. 

JSAF  is  capable  of  receiving  and  processing  several  types  of  information  via  HLA.  This 
includes  entity  state  information  output  by  other  simulations  within  the  federation.  For 
example,  JSAF  reads  the  states  of  civilian  vehicles  and  pedestrians  that  are  modeled  by  the 
clutter  simulation,  and  displays  them  on  the  JSAF  Plan  View  Display.  Any  such  external  entities 
are  visible  to  the  JSAF-controlled  entities;  they  can  be  detected,  fired  at,  collided  with,  etc.  JSAF 
also  reads  the  weather  state  infonnation  output  by  OASES,  although  most  platform  and 
equipment  models  within  JSAF  do  not  make  use  of  such  information.  JSAF  also  reads  messages 
describing  changes  to  the  terrain  that  are  output  by  DT-SIM.  Such  dynamic  terrain  changes 
(e.g.,  the  appearance  of  a  bomb  crater)  can  affect  the  movement  of  ground  vehicles  in  JSAF. 


Figure  2.3.  JSAF  Plan  View  Display  with  Air  Dynamics  Editor 
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The  primary  output  of  JSAF  is  entity  state  information  for  all  of  the  entities  that  it  models.  It 
also  outputs  various  types  of  interactions,  including  weapons  fire  and  detonation,  collision,  etc. 
In  support  of  various  exercises  and  experiments,  JSAF  has  been  extensively  modified  to  support 
additional  FOMs.  It  includes  an  extensive  FOM  agility  layer.  Many  of  its  outputs  are  platfonn- 
or  weapon-system  specific. 

Figure  2.3  shows  the  JSAF  Plan  View  Display  (PVD),  with  a  map  background  (in  this  case 
showing  terrain  elevation  and  roads)  and  various  platform-level  icons.  The  toolbar  at  the  upper 
right  provides  access  to  a  variety  of  tools  for  creating,  tasking,  and  otherwise  manipulating  the 
simulated  entities.  The  window  at  the  bottom  shows  the  Aircraft  Dynamic  control  panel,  which 
can  be  used  to  manipulate  the  flight  and  fuel  consumption  characteristics  of  a  particular  aircraft. 
Multiple  copies  of  the  JSAF  PVD  can  be  run  simultaneously.  Commonly,  some  JSAF  GUIs  are 
congifured  as  controller  workstations,  which  see  and  can  manipulate  all  entities,  while  others  are 
configured  as  “player”  workstations,  which  can  see  only  their  own  forces,  as  well  as  any  enemy 
forces  that  have  been  detected. 

2.2.2  OASES 

The  OASES  system  is  a  suite  of  applications  for  creating  and  managing  a  three-dimensional, 
time-varying,  digital  representation  of  the  natural  environment.  OASES  has  been  used  primarily 
to  provide  natural  environments  (SNEs)  to  systems  of  networked  military  training  simulations 
running  on  the  Department  of  Defense’s  (DoD)  High  Level  Architecture  (HLA).  The  simulated 
natural  environments  created  by  OASES  are  based  on  authoritative,  validated  numerical  models, 
typically  the  same  models  that  are  used  by  METeorologicaPOCeanographic  (METOC)  personnel 
in  support  of  real-world  military  operations.  OASES  provides  tools  for  converting  authoritative 
model  outputs  to  a  data  format  recognized  by  all  of  the  OASES  applications.  This  format 
supports  the  data  access  requirements  of  distributed  simulations  that  integrate  virtual  and/or  live 
entities  and  which  must  operate  in  real-time.  Additionally,  OASES  provides  tools  for  tailoring 
the  SNE,  either  before  the  simulation  begins  or  while  it  is  running,  to  meet  exercise-specific 
requirements  for  environmental  phenomena. 

The  original  development  of  the  OASES  system  was  sponsored  by  the  Defense  Advanced 
Research  Project  Agency  (DARPA),  under  the  name  TAOS  (Total  Atmosphere  Ocean  Services), 
in  support  of  the  Synthetic  Theater  of  War  (STOW)  1997  Program.  In  1998,  DARPA  funded  the 
development  of  a  low-resolution  worldwide  atmospheric  and  oceanographic  database,  also 
known  as  the  Global-98  database,  for  use  by  the  JSIMS  program.  In  1999,  the  United  States 
Space  Command’s  (USSPACECOM)  Space  Warfare  Center  funded  extensions  to  TAOS  to 
support  the  space  environment,  specifically  ionospheric  effects  on  precision-guided  missiles,  as 
part  of  the  PSM+  (extended  Portable  Space  Model)  project.  More  recently,  funding  for 
continued  development  and  integration  with  the  HLA,  under  the  name  OASES,  has  been 
provided  primarily  by  DMSO  through  the  Environment  Federation  (EnviroFed)  projects. 

Figure  2.4  shows  the  OASES  subsystems  and  the  data  flows  among  them.  OASES  converts 
current  and  forecast  environmental  data,  provided  by  physics-based  operational  and  research 
models,  into  a  fonn  that  can  be  used  by  distributed  simulations  running  on  the  HLA. 


6 


The  OASES  system  consists  of  five  primary  subsystems.  The  OASES  Ingestor  converts  all  input 
model  data  to  a  common  run-time  format  that  is  recognized  by  all  OASES  subsystems.  The 
external  data  providers  are  identified  in  the  rounded-rectangles  on  the  left  side  of  the  figure.  The 
OASES  Transformer  uses  a  set  of  transformation  algorithms  to  augment  existing  OASES 
databases  with  various  environmental  parameters  that  are  not  provided  directly  by  an  external 
data  source,  but  that  are  required  by  the  simulations  served  by  OASES.  The  OASES  Editor 
allows  users  to  tailor  the  contents  of  an  OASES  database.  The  Editor  provides  three  editing 
algorithms:  1)  replacement  at  a  point  with  gaussian  spatial  and  temporal  blending,  2)  a  Pressure 
Field  Modification  (PFM)  algorithm  for  editing  atmospheric  environments  while  preserving 
correlation  between  temperature,  pressure,  wind  and  relative  humidity,  and  3)  a  precipitation 
editing  algorithm.  The  Editor  can  be  used  to  prepare  scripted  changes  to  an  existing  METOC 
scenario,  or  it  can  be  used  at  run-time  to  modify  the  SNE  during  a  simulation  exercise.  The 
OASES  Time  Federate  and  Publisher  are  the  subsystems  that  interface  directly  to  the  HLA 
Federation;  that  is,  they  are  the  OASES  Federates.  They  create  and  update  the  objects  that 
encapsulate  the  state  of  the  simulated  natural  environment  via  services  provided  by  the  RTI.  The 
Time  Federate  creates  objects  that  establish  the  time-dependence  of  the  SNE  while  the  Publisher 
manages  objects  that  encapsulate  its  spatial-dependence. 
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Figure  2.5.  OASES  Weather  Visualization 

The  OASES  Visualizer  is  a  tool  for  visualizing  the  contents  of  an  OASES  database.  It  is  used  to 
validate  databases  built  by  the  Ingestor  and/or  extended  by  the  Transfonner,  to  review  the  results 
of  edits  applied  by  the  OASES  Editor,  to  monitor  the  current  state  of  the  SNE  created  by  the 
Publisher,  and/or  to  monitor  the  current  state  of  the  SNE  as  received  by  the  OASES  Subscriber. 
An  example  of  an  OASES  Visualizer  display  is  shown  in  Figure  2.5. 

Finally,  the  OASES  Receiver  is  responsible  for  polling  local  or  remote  data  sources,  using  the 
Internet  File  Transfer  Protocol  (FTP),  for  environmental  data  transmittals  matching  a  user- 
specified  file-naming  pattern.  The  Receiver  is  the  subsystem  that  supports  the“Live  Mode”  of 
OASES,  in  which  the  simulated  natural  environment  is  continuously  updated  based  on  the  data 
received  from  current  and  forecast  environmental  models  running  in  real-time. 

Within  the  JSB-RD  environment,  OASES  is  used  to  bring  in  weather  information  from  Air  Force 
and  Navy  sources.  OASES  outputs  weather  state  information,  including  temperature,  pressure, 
and  precipitation  information,  in  one-dimensional  (profile),  two-dimensional  (surface),  and 
three-dimensional  forms,  over  HLA.  This  information  is  read  by  JSAF  and  DT-SIM,  which  use 
it  to  modify  some  military  operations,  and  to  implement  changes  to  the  terrain  database, 
respectively. 
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2.2.3  DT-SIM 

The  Dynamic  Terrain  Simulation  (DT-SIM)  models  changes  to  the  terrain  component  of  the 
environment.  The  changes  result  from  various  types  of  simulation  events,  including  weapon 
detonations,  movement,  weather  effects,  and  military  engineering  operations,  such  as  the 
creation  and  destruction  obstacles.  DT-SIM  receives  interaction  events  from  JSAF,  and 
determines  what  effect,  if  any,  they  have  on  the  geometry  or  attributes  of  the  terrain  at  the 
location  event.  For  example,  when  DT-SIM  receives  a  weapon  detonation  interaction  from 
JSAF,  it  may,  depending  on  the  type  of  the  weapon  and  its  proximity  to  the  terrain  surface,  or  a 
specific  terrain  feature,  determine  that  a  crater  should  be  created,  or  that  a  building  should  be 
damaged.  DT-SIM  updates  its  internal  terrain  representation,  and  publishes  messages  over  HLA 
describing  how  the  terrain  has  changed.  These  messages  are  used  by  JSAF  to  update  its  terrain 
representation,  which  in  turn  affects  how  some  activities  are  carried  out.  For  example,  the 
appearance  of  a  new  crater  may  change  the  movement  of  vehicles  to  avoid  it.  Weather  effects, 
such  as  prolonged  rain,  may  also  change  the  characteristics  of  the  terrain,  restricting  the  speed  of 
cross-country  movement. 

2.2.4  Clutter  Simulation 

The  clutter  simulation,  which  is  part  of  the  JSAF  distribution,  models  the  movements  of  civilian 
vehicles  and  pedestrians.  The  amount  and  type  of  clutter  is  specified  using  clutter  templates. 
Each  template  specifies  a  list  of  entity  types  with  associated  relative  weights,  as  well  as  a 
collection  of  control  points.  Each  control  point  specifies  a  center  location,  a  radius  (defining  a 
circular  area),  and  a  number  of  clutter  entities.  Each  control  point  is  identified  as  defining  a 
static  clutter  area,  a  mobile  clutter  area,  a  clutter  source,  or  a  clutter  sink.  Clutter  entities  move 
randomly  within  a  static  clutter  area.  Sources  and  sinks  allow  dynamic  traffic  flows  to  be 
created.  Clutter  etities  are  randomly  created  in  the  source  areas,  and  move  to  random  locations 
within  a  sink  area.  When  they  arrive,  they  are  destroyed  and  replaced  with  a  new  entity  in  one  of 
the  source  areas.  The  clutter  simulation  publishes  entity  state  information  for  each  of  the  clutter 
entities  as  they  move. 

2.2.5  MC02  Federation  Object  Model 

The  JSB-RD  simulation  environment  currently  uses  a  version  of  the  Millenium  Challenge  2002 
(MC02)  federation  object  model  (FOM).  The  MC02  FOM  is  based  on  the  Realtime  Platform 
Reference  (RPR)  FOM,  which  was  designed  to  map  the  original  DIS  protocols  into  an  HLA 
environment.  The  MC02  FOM  includes  a  number  of  objects  and  interactions  that  were  added  to 
support  specific  aspects  of  the  Millenium  Challenge  2002  exercise.  Most  of  these  are  not  used 
within  the  JSB-RD  environment.  The  elements  of  the  MC02  FOM  that  are  currently  used 
include: 

■  the  BaseEntity/PhysicalEntity/Platform  class,  primarily  the  GroundVehicle  and  Aircraft 
subclasses, 

■  the  Atmosphere,  SurfaceWeather,  and  Weather  classes,  and  their  various  subclasses,  and 

■  the  Collision,  Weapon  Fire,  and  Munition  Detonation  interactions. 
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The  JSB-RD  environment  conforms  to  the  MC02  Federation  Agreements,  Spiral  3-10,  May 

2002. 

2.2.6  Integrated  Situation  Viewer 

The  Integrated  Situation  Viewer,  commonly  referred  to  simply  as  “the  Viewer”,  is  intended  to 
support  experimentation  with  theater-level  air  mission  situation  awareness  and  dynamic 
retasking.  The  Viewer  displays  simulation  state  information  describing  air  missions,  which  is,  in 
effect,  ground  truth,  and  the  corresponding  Air  Battle  Plan  infonnation,  as  well  as  any 
information  (derived  from  the  simulation)  that  reflects  the  reported  or  perceived  current 
situation,  as  output  by  various  sensor  models.  In  its  current  form,  the  Viewer  consists  of  a 
number  of  loosely  coupled  components.  Figure  2.6  shows  the  architecture  for  the  Viewer,  which 
is  based  on  the  classic  Model- View-Controller  paradigm. 

The  back-end  portion  of  the  Viewer  consists  of  a  collection  of  components  that  are  capable  of 
reading  data  from  various  sources.  Simulation  entity  state  and  event  data  output  by  JSAF, 
OASES,  DT-SIM,  and  other  simulations  is  read  via  an  HLA-to-XML  gateway.  This  gateway 
converts  entity  state  infonnation  received  over  HLA  into  a  stream  of  XML  messages.  It  also 
performs  coordinate  conversion  (from  the  geocentric  coordinates  used  by  the  MC02  FOM  to 
geodetic  coordinates),  and  partial  translation  of  the  DIS  Entity  Bit  Vector  (EBV)  fields  that  are 
used  to  hierarchically  identify  entities  by  nationality,  domain,  type,  subtype,  etc.  Other  data 
sources,  including  JSAF  input  spreadsheets,  are  read  directly  from  the  appropriate  files. 

The  “heart”  of  the  Viewer  consists  of  an  integrated  domain  model  that  stores  and  maintains 
information  on  air  mission  plans,  individual  aircraft,  and  their  targets.  The  data  read  from  the 
various  back-end  sources  is  used  to  populate  and  update  this  model. 

The  front-end  of  the  Viewer  consists  of  multiple  views  of  the  information  that  the  domain  model 
contains.  Several  types  of  views  are  supporting,  including: 

■  Map  views  -  displaying  the  locations  of  aircraft  and  targets,  planned  and  actual  flight 
paths,  etc.,  overlaid  on  a  map  background,  at  multiple  scales  and  resolutions,  using  the 
JView  visualization  toolkit  developed  by  AFRL/IFSB  (see  Figure  2.7), 

■  Tabluar  views  -  listing  entities  of  various  types  (aircraft,  targets,  missions,  etc.)  and  their 
relevant  characteristics,  and  capable  of  being  sorted  and  ordered  in  various  ways, 

■  Text  views  -  displaying  a  streaming  list  of  text  messages,  generated  by  the  Simulation 
Network  News  (SNN)  utility,  which  is  part  of  the  JSAF  distribution. 
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HLA 


Figure  2.6.  Viewer  Architecture 


The  Controller  is  the  “brain”  of  the  Viewer,  coordinating  all  of  the  other  components.  When 
new  information  arrives  from  one  of  the  sources,  the  Controller  triggers  the  updating  of  the 
domain  model,  and  then  the  updating  of  all  views  that  are  affected  by  the  change.  Similarly, 
when  the  interactively  changes  a  piece  of  information  in  one  of  the  views,  the  Controller  triggers 
the  updating  of  the  domain  model,  and  then  the  updating  of  any  other  views  that  are  affected  by 
the  change.  The  Controller  also  coordinates  the  selection  of  entities  and  locations  across  all  of 
the  views,  so  that  an  entity  that  is  selected  in  one  of  the  views  is  also  highlighted  in  all  other 
views  in  which  it  appears.  A  Controller  GUI  allows  the  user  to  select  which  types  of  views 
should  be  displayed,  and  what  the  content  of  each  should  include. 
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Figure  2.7.  Viewer  Map  View 

A  planned  enhancement  to  the  Viewer  will  make  use  of  a  custom  implementation  of  the  Java 
Naming  and  Directory  Interface  (JNDI),  developed  by  AFRL/IFSB,  to  allow  views  to  be 
“cloned”  across  multiple  workstations  and  monitors. 

2.2.7  Simulation  Preparation 

The  Simulation  Preparation  component  of  the  JSB-RD  environment  allows  existing  Air  Battle 
Plans  (ABPs)  contained  within  the  Air  Operations  Data  Base  (AODB)  of  the  Theater  Battle 
Management  Core  System  (TBMCS)  to  be  converted  into  sets  of  JSAF  input  spreadsheets  that 
can  be  executed  using  JSAF.  This  component  extracts  a  specified  ABP  from  the  AODB,  which 
contains  specifications  of  multiple  air  missions  of  various  types.  Each  mission  specification 
includes  the  numbers  and  types  of  aircraft  involved  in  the  mission,  their  takeoff  and  return  times 
and  bases,  and  a  sequence  of  key  mission  events.  These  mission  events  include  takeoff, 
refueling  (start  and  end),  time  on  target  (start  and  end),  and  landing.  Ground  attack  missions 
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also  identify  their  targets.  Supporting  infonnation  describing  the  mission  targets  is  extracted 
from  the  MIDB. 

The  basic  mission  infonnation,  along  with  a  list  of  the  air  defense  threats  in  the  area,  can  be  fed 
to  a  separate  Routing  application,  which  detennines  the  “best”  route  for  each  mission  to  and 
from  its  assigned  target  while  avoiding  air  defense  threats.  The  returned  route  contains  a  number 
of  intennediate  waypoints  that  the  aircraft  should  pass  through  on  the  way  to  and  from  their 
target. 

This  information  is  then  used  to  generate  a  JSAF  input  spreadsheet.  The  spreadsheet  contains 
two  entries  for  each  scheduled  air  mission,  one  describing  the  ingressing  leg  of  the  mission,  and 
the  other  describing  the  return  leg.  Each  entry  specifies,  in  JSAF  terms,  the  number  and  type  of 
aircraft,  the  call  sign(s)  of  the  aircraft,  the  type  of  task  to  be  performed,  the  take  off  and  return 
times,  and  the  base  and  target  locations.  A  second  spreadsheet  contains  the  intermediate  route 
points,  linked  via  the  call  signs. 


3.  LESSONS  LEARNED 

This  section  summarizes  the  lessons  learned  during  this  effort.  The  key  accomplishments 
achieved  under  this  effort  include: 

•  development  of  limited  capabilities  to  extend  and  modify  JSAF, 

•  development  of  a  capability  to  use  JSAF  to  execute  Air  Battle  Plans  extracted  from  the 
TBMCS  Air  Operations  Data  Base, 

•  development  of  the  HLA-to-XML  gateway  to  translate  distributed  simulation  message 
traffic  over  HLA  into  a  stream  of  XML  messages, 

•  separation  of  the  Viewer  into  a  collection  of  loosely  coupled  components  using  the 
classic  Model-View-Controller  paradigm. 

Each  of  these  discussed  in  the  subsections  below.  Finally,  conclusions  and  recommendations  are 
given. 

3.1  JSAF  Modification 

JSAF  is  not  a  packaged  software  product.  There  does  not  appear  to  be  an  active  JSAF 
user/developer  community,  with  mailing  lists,  news  groups,  and  other  such  resources,  where 
newer  users  can  go  to  find  answers  to  their  questions.  There  is  no  JSAF  help  desk,  or  any  other 
similar  type  of  support  mechanisms.  JFCOM  J9  maintains  a  staff  of  more  than  30  developers 
who  are  constantly  modifying  and  extend  JSAF  to  meet  the  requirements  of  an  ongoing  series  of 
simulation  experiments.  Although  the  JSAF  development  staff  has  been  helpful  in  finding 
answers  to  some  questions,  supporting  external  users  of  JSAF  is  not  a  high  priority. 

With  help  from  the  JSAF  developers,  we  have  learned  to  make  several  minor  types  of  additions. 
These  include: 

•  Adding  a  new  type  of  platform/vehicle, 
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•  Adding  new  components  to  an  existing  platform/vehicle, 

•  Adding  a  new  type  of  military  unit, 

•  Adding  a  new  high-level  taskframe  for  an  air  mission, 

•  Changing  the  values  of  parameters  associated  with  a  platform/vehicle  or  high-level  task 
frame. 

The  JSAF  software  appears  to  contain  an  impressive  degree  of  functionality.  However,  closer 
examination  reveals  that  much  of  the  functionality  that  appears  to  be  present  is  difficult  or 
impossible  to  access.  JSAF  has  been  modified  extensively  over  the  years  to  meet  specific  needs 
of  particular  exercises  and  experiments.  It  appears  that  many  of  these  modifications  were  never 
completed,  or  never  worked  successfully,  but  they  remain  in  the  JSAF  software  distribution.  In 
some  cases,  it  appears  that  capabilities  were  added  at  one  point,  but  were  later  incompletely 
removed,  leaving  unused  entries  in  data  files,  etc.  For  example,  under  this  effort  the  existing 
Link-16/TADIL-J  communications  functionality  within  JSAF  was  investigated.  JSAF  contains  a 
number  of  software  libraries  that  appear  to  support  this  functionality,  as  well  as  data  elements. 
The  MC02  FOM  includes  messages  that  describe  Link- 16  radios  and  TADIL-J  messages.  We 
ran  several  experiments  attempting  to  use  aircraft,  as  well  as  surface  ships,  equipped  with  Link- 
16  components.  However,  we  were  never  able  to  observe  any  communication  between  these 
platforms,  or  any  sharing  of  the  awareness  of  targets  being  detected  by  other  platforms  within  a 
Link- 16  network. 

JSAF  does  a  reasonable  job  of  simulating  the  movement  of  physical  entities  from  one  location  to 
another.  It  also  does  a  reasonable  job  of  simulating  many  types  of  individual  weapons  and  the 
related  combat  activities.  It  can  model  tactical  aircraft  and  simple  air  missions  adequately. 
Although  it  does  model  some  types  of  sensors,  including  the  detection  of  targets,  it  does  not 
model  the  tracking  or  reporting  or  dissemination  of  information  resulting  from  sensor  detections 
to  other  entities.  It  does  not  model  most  ISR  assets  (e.g.,  AWACS,  JSTARS,  UAVs)  with  useful 
realism.  It  should  be  noted  that  for  the  current  Urban  Resolve  experiment,  JFCOM  J9  did  not  use 
JSAF  for  sensor  modeling,  but  instead  relied  on  the  expensive  COTS  software  package 
SLAMEM™  (Simulation  of  the  Locations  and  Attack  of  Mobile  Enemy  Missiles)  from  Toyon 
Research  Corporation. 

The  JSAF  software  distribution  is  extremely  large  and  complex.  It  now  consists  of  more  than 
1000  individual  object  libraries.  A  complex  web  of  dependencies  connects  these  libraries  to  one 
another.  The  JSAF  software  is  primarily  written  in  ANSI  C,  but  has  a  complex  object-based 
structure  that  simulates  inheritance  and  aggregation  relationships  among  libraries.  Extensive 
configuration  script  and  reader  (i.e.,  data)  files  further  add  to  this  complexity.  This  complexity 
makes  the  JSAF  software  extremely  difficult  to  understand.  JSAF  documentation  is  extremely 
limited.  Many  of  the  libraries  have  no  documentation  whatsoever. 

JSAF  has  two  interfaces  for  creating  scenarios.  One  is  the  interactive  Unit  Editor,  which  allows 
military  units  and  platfonns  to  be  created,  placed  on  the  Plan  View  Display,  and  given  tasks. 
Once  created,  scenarios  can  be  saved  to  files,  for  reloading  later.  The  second  interface  is  the 
Spreadsheet  mechanism,  which  allows  spreadsheets  specifying  air  mission  infonnation  to  be 
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read  in,  from  which  the  necessary  aircraft  are  created  and  then  tasked.  Spreadsheets  can  also  be 
written  out,  but  without  any  tasking  infonnation.  Oddly,  there  is  very  little  overlap  between  the 
aircraft  tasks  that  can  be  assigned  using  these  two  mechanisms.  Tasks  that  can  be  assigned 
interactively  using  the  Unit  Editor  generally  cannot  be  assigned  using  the  Spreadsheet 
mechanism,  while  the  mission  types  that  can  be  assigned  using  the  Spreadsheet  mechanism 
cannot  be  assigned  using  the  Unit  Editor.  The  Unit  Editor  also  offers  a  number  of  interactive 
commands  (e.g.,  Fly  Higher/Fly  Lower)  that  cannot  be  accessed  through  other  mechanisms.  In 
particular,  there  is  no  mechanism  that  allows  military  units  to  be  tasked  via  an  HLA  message 
from  another  federate. 

3.2  JSAF  Scenario  Preparation 

The  ability  to  extract  an  Air  Battle  Plan  from  the  TBMCS  Air  Operations  Data  Base,  along  with 
supporting  target  information  from  the  MIDB,  and  generate  a  JSAF  input  spreadsheet  that  can  be 
used  to  execute  those  air  missions,  is  a  very  powerful  tool.  When  used  in  conjunction  with  a 
realistic  mission  route  generator  that  takes  into  account  known  air  defense  threats,  it  provides  an 
even  more  important  capability. 

However,  there  are  currently  several  limitations  to  this  capability.  Currently,  this  requires 
multiple  queries  of  AODB  and  MIDB  tables,  followed  by  the  joining  of  these  tables.  It  would  be 
convenient  if  this  information  could  be  easily  queried  via  JBI  by  specifying  an  Air  Battle  Plan 
name.  It  would  also  be  nice  if  a  list  of  the  Air  Battle  Plans  contained  within  the  AODB  was 
easily  accessible. 

There  are  also  several  issues  concerning  the  translation  of  ABP  information  into  JSAF  input. 
AODB  aircraft  types  must  be  translated  into  corresponding  JSAF  entity  types.  The  necessary 
JSAF  entities  are  created  for  each  specified  air  mission.  This  makes  it  difficult  for  a  particular 
aircraft  to  fly  multiple  missions  in  sequence.  ABP  mission  numbers  are  not  used  by  JSAF. 
Instead,  the  call  signs  for  each  mission  in  the  ABP  are  augmented  with  unique  numeric  IDs,  and 
are  inserted  into  the  “markings”  field  of  the  JSAF  entities.  These  call  signs  are  not  always 
unique.  The  mission  types  specified  in  the  ABP  must  be  translated  into  JSAF  air  mission  task 
frames.  Currently,  the  task  frames  used  are  Interdiction/ Attack  Ground  for  strike  missions,  FWA 
Hold  for  orbiting  (including  CAP,  tankers,  etc.),  and  Return  to  Base.  Finally,  the  route  points 
that  can  be  entered  into  JSAF  are  two-dimensional  (latitude-longitude).  Altitude  is  specified 
indirectly,  as  a  parameter  of  the  top-level  task  frame.  This  makes  it  difficult  to  specify  mission 
profiles  that  depend  on  variations  in  altitude. 

3.3  HLA-to-XML  Gateway 

The  HLA-to-XML  gateway  allows  multiple  applications,  such  as  the  Viewer,  to  access  the 
stream  of  information  coming  out  of  the  simulations  without  having  to  deal  with  the 
complexities  of  HLA.  However,  the  HLA-to-XML  gateway  currently  has  several  limitations.  It 
currently  provides  only  entity  state  information.  It  does  not  currently  publish  MC02  FOM 
interactions,  such  as  collisions,  weapon  fire,  and  munition  detonation  events.  The  entity  state 
information  is  published  as  a  simple  sequence  of  entity  states.  However,  these  are  not  time 
stamped;  they  are  simply  provided  “in  real-time”  as  they  are  received.  Also,  the  translation  of 
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entity  state  fields  is  currently  limited  to  coordinates,  force  identifier,  and  damage  state,  leaving 
the  application  to  deal  with  the  more  difficult  translation  of  the  seven  EBV  fields  that  identify 
the  type  of  the  entity.  Finally,  the  HLA-to-XML  gateway  currently  operates  in  only  one 
direction.  Therefore,  it  only  supports  “receive-only”  federates.  Any  HLA  messages  that  an 
application  needs  to  send  back  to  the  simulation  to,  for  example,  retask  an  aircraft,  must  use 
another  mechanism. 

3.4  Viewer  Architecture 

The  reorganization  of  the  Viewer  into  a  collection  of  loosely  coupled  components  has 
significantly  enhanced  its  long-tenn  potential  to  incorporate  a  wide  variety  of  visualization  and 
interaction  techniques.  However,  in  the  short  tenn,  this  reorganization  has  resulted  in  the  loss  of 
some  capabilities  that  previously  existed  within  the  Viewer.  Three-dimensional  views  are  no 
longer  included,  though  they  could  be  easily  restored.  Support  for  re  tasking  has  also  been  lost, 
though  this  is  primarily  due  to  the  replacement  of  Interactive  Suppressor  with  JSAF  as  the 
primary  simulation  component  wthin  the  JSB-RD  simulation  environment. 

Also,  the  current  Scenario  Preparation  implementation,  which  extracts  data  from  the  AODB  and 
MIDB  and  generates  a  JSAF  input  spreadsheet  in  a  single  integrated  step,  makes  it  difficult  for 
the  Viewer  to  access  the  original  source  data  without  re-extracting  it  from  the  AODB  and  MIDB. 

3.5  Conclusions  and  Recommendations 

The  conclusions  and  recommendations  resulting  from  this  effort  are  summarized  below: 

1.  JSAF  has  been  used  successfully  by  a  number  of  large  programs,  including  Joint  Strike 
Fighter  (JSF),  EnviroFed,  and  Distributed  Mission  Training  (DMT),  and  the  use  of  JSAF 
facilitates  the  development  of  a  closer  relationship  between  AFRL  and  JFCOM.  However, 
JSAF  is  not  very  suitable  for  use  within  a  small,  dynamic  laboratory  environment.  It  requires 
a  large,  highly  trained,  and  highly  skilled  staff  to  maintain,  to  operate,  and  especially  to 
modify  or  extend  it.  Extending  or  modifying  the  JSAF  software  in  support  of  a  specific 
simulation  experiment  is  difficult  and  time-consuming.  Although  it  can  be  integrated  with 
other  existing  tools  and  C4ISR  systems,  this  is  not  easy  to  accomplish.  Continued  use  of 
JSAF  within  the  AFRL/IFSB  modeling  and  simulation  laboratory  will  require  a  significant 
commitment  to  develop  and  maintain  a  skilled  and  experienced  staff. 

a)  Obtain  and  install  the  current  version  of  JSAF  (Version  6).  In  this  new  version,  aircraft 
of  all  types  have  been  converted  to  a  new,  more  realistic  flight  dynamics  model.  The 
clutter  simulation  has  also  been  significantly  improved  in  support  of  the  Urban  Resolve 
exercise. 

b)  Continue  to  investigate  the  JSAF  software  and  to  learn  how  to  modify  and  extend  it.  This 
includes: 

i)  Extending  the  spreadsheet  input  mechanism  to  support  additional  types  of  air 
missions. 
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ii)  Learning  to  create  new  air  mission  task  frames,  and  to  modify  existing  air  mission 
task  frames. 

iii)  Learning  how  to  extend  the  existing  interactive  tasking  interface  to  support  the 
tasking  and  retasking  of  entities  from  external  applications,  such  as  the  Viewer. 

iv)  Learning  how  to  define  new  object  and  interaction  messages  to  be  output  by  JSAF, 
and  to  modify  existing  output  messages. 

c)  Consider  augmenting  the  use  of  JSAF  with  other,  more  modern  entity  level  simulations, 
such  as  JIMM  and/or  EADSIM.  Copies  of  these  simulations  should  be  obtained, 
installed,  and  evaluated  with  respect  to  their  usability  and  flexibility. 

2.  Extend  the  Scenario  Preparation  software  to  publish  the  Air  Battle  Plan  and  associated  order 
of  battle  infonnation  in  XML  form,  unless  this  information  can  be  obtained  directly  in  XML 
form  using  TBMCS  version  1.1.3.  This  information  can  then  be  input  by  the  Viewer, 
allowing  the  planned  missions  to  be  compared  with  the  actual  execution  of  those  missions. 

3.  Improve  the  XML-to-HLA  gateway  to  support  MC02  FOM  interactions  including  weapon 
fire  and  munition  detonation,  takeoff  and  landing,  and  entity  removal,  and  to  add  a  time 
stamp  to  the  XML  representation  of  each  published  HLA  message. 

4.  Enhance  the  Viewer  to  display  additional  air  mission-related  information,  and  to  display 
information  in  additional  forms.  This  includes: 

a)  Display  of  MC02  FOM  interactions,  including  weapon  fire  and  munition  detonation,  and 
takeoff  and  landing,  as  well  as  entity  removal. 

b)  Display  of  planned  mission  information  from  the  Air  Battle  Plan,  and  graphical 
comparison  of  planned  mission  states  with  actual  mission  states. 

c)  Three-dimensional  views  that  can  be  attached  to  a  specific  aircraft  or  group  of  aircraft. 

d)  Vector  map  data  (e.g.,  VMap  Level  0,  1,  or  2)  overlaid  on  terrain  elevation  data. 

e)  Time  line/Gantt  chart  type  displays  showing  planned  and  actual  mission  event  (takeoff, 
on  target,  return,  etc.)  times. 

f)  Addition  of  improved  controls  for  customizing  individual  views,  as  well  as  creating, 
naming,  storing,  and  retrieving  collections  of  views  including  view  configuration  (i.e., 
window  size  and  placement)  infonnation. 

5.  Publish  simulation  events  that  correspond  to  planned  mission  events,  including  takeoff  and 
landing,  weapon  fire  and  munition  detonation,  start  and  end  of  refueling,  etc.,  via  the  HLA- 
to-JBI  gateway,  so  that  they  may  be  accessed  by  CAOC-21  applications. 


4.  ACRONYMS 

This  section  provides  a  listing  of  acronyms  and  their  meanings  as  used  in  this  document. 
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ABP 

Air  Battle  Plan 

AFRL 

Air  Force  Research  Laboratory 

AOC 

Air  Operations  Center 

AODB 

Air  Operations  Data  Base 

ATO 

Air  Tasking  Order 

ATAOC 

Advanced  Technology  Air  Operations  Center 

AWACS 

Airborne  Warning  and  Control  System 

C4ISR 

Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance,  and  Reconnaissance 

CADRG 

Compressed  ARC  Digital  Raster  Graphics 

CDRL 

Contract  Data  Requirements  List 

CGF 

Computer  Generated  Forces 

COA 

Course  of  Action 

COTS 

Commercial  Off  The  Shelf 

CPE 

Commander’s  Predictive  Environment 

CRC 

Control  and  Reporting  Center 

CSE 

Common  Simulation  Environment 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DIS 

Distributed  Interactive  Simulation 

DMSO 

Defense  Modeling  and  Simulation  Office 

DMT 

Distributed  Mission  Training 

DoD 

Department  of  Defense 

DSAP 

Dynamic  Situation  Awareness  and  Prediction 

DTED 

Digital  Terrain  Elevation  Data 

DT-SIM 

Dynamic  Terrain  Simulation 

EBO 

Effects  Based  Operations 

EBV 

Entity  Bit  Vector 

EOB 

Enemy  Order  of  Battle 

ESC 

Electronic  Systems  Command 

FOM 

Federation  Object  Model 

FWAEE 

Fixed  Wing  Aircraft  Exercise  Editor 

GUI 

Graphical  User  Interface 

HE 

Human  Effectiveness  Directorate  (of  AFRL) 

HLA 

High  Level  Architecture 

IFSB 

C4ISR  Modeling  &  Simulation  Branch 

IF 

Information  Directorate  (of  AFRL) 

IFT 

Technology  Division 

JBI 

Joint  Battlespace  Infosphere 
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JEFX 

JFCOM 

JIMM 

JIPTF 

JNDI 

JSAF 

JSB 

JSB-DS 

JSB-RD 

JSIMS 

JSTARS 

MAAP 

MARCI 

MC02 

METOC 

MIDB 

ModSAF 

NGMS 

NIMA 

OASES 

OPFOR 

PBA 

PFM 

PSM 

PVD 

RPR 

RRS 

RTI 

SAA 

SAM 

SEDRIS 

SNE 

SNN 

STF 

STOW 

SWEG 

TAOS 

TBMCS 


Joint  Expeditionary  Force  exercise 

Joint  Forces  Command 

Joint  Integrated  Mission  Model 

Joint  Integrated  Prioritized  Target  List 

Java  Naming  and  Directory  Interface 

Joint  Semi- Automated  Forces 

Joint  Synthetic  Battlespace 

Joint  Synthetic  Battlespace  -  Decision  Support 

Joint  Synthetic  Battlespace  for  Research  and  Development 

Joint  Simulation  System 

Joint  Surveillance  and  Target  Attack  Radar  System 
Master  Air  Attack  Plan 

Multi-system  Automated  Remote  Control  and  Instrumentation 

Millenium  Challenge  2002 

Meteorological/Oceanographic 

Modern  Integrated  Data  Base 

Modular  Semi  Automated  Forces 

Northrop  Grumman  Mission  Systems 

National  Imagery  and  Mapping  Agency 

Ocean,  Atmosphere,  and  Space  Environmental  Services 

Opposing  Force 

Predictive  Battlespace  Awareness 
Pressure  Field  Modification 
Portable  Space  Model 
Plan  View  Display 
Realtime  Platform  Reference 
Rome  Research  Site 
Run  Time  Infrastructure 
Situation  Awareness  and  Analysis 
Surface  to  Air  Missile 

Synthetic  Environment  Data  Representation  and  Interchange  Specification 

Synthetic  Natural  Environment 

Simulation  Network  News 

SEDRIS  Transmittal  Format 

Synthetic  Theater  of  War 

Simulated  Warfare  Environment  Generator 

Total  Atmosphere  Ocean  Services 

Theater  Battle  Management  Core  System 
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UAV  Unmanned  Aerial  Vehicle 

USATEC  U.S.  Anny  Topographic  Engineering  Center 

USSPACECOM  U.S.  Space  Command 

VMap  Vector  Smart  Map 

VPF  Vector  Product  Format 

XML  extensible  Markup  Language 
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